前面已經大概介紹了一下 NiFi 的用途還有特性，那今天就來講在 NiFi 中，其實是可以對一組 Data Pipieline 來做一個『版本控制』，就類似於 git 一樣，git 可以將每次修改好的版本 commit 出去且 push 到 Github 或 Gitlab 平台上對應的 respository。那 NiFi 是如何做到的呢？答案是今天的主角 - NiFi Registry。

為什麼要版本控制？

在開始講 NiFi Registry 之前，先來簡單探討一下為什麼 NiFi 需要做版本控制？原因有幾點:

1. 假如是一個 team，在前一篇有提到很多時候會透過 Process Group 來作為分 team 的依據，而底下會有很多隸屬於該 team 的 project，若太多 members 在上面做修改的話，會導致 Pipiline 變得一團糟，所以就可以透過版控的方式來確定穩定且最新的版本，好讓 members 在每次修改或開發 project 時是一致的版本。
2. 搭配 Staging 和 Production 的環境來做 CI/CD，很多時候我們會到一定的版本時就會 deploy 到 Staging 或 Production 做測試及應用，這時候版控也可以讓我們清楚知道目前環境的版本，同時也使我們容易整合 CI/CD 的來做到deployment。

NiFi Registry

NiFi Registry 是一個額外獨立的服務，他同時也是 NiFi 的 sub-project。其中他有幾個地方需要留意：

1. 是一個獨立 Service, 最小版控單位是 Processor Group

NiFi Registry Sturcture

首先先看我設計的架構圖:

從圖上我們可以看到在 NiFi Registry 建立於 Bucket，而Bucket底下可以有很多 Flow(也就是 Processor Group 為單位)，再針對 Flow 來做版控。

這樣講可能讀者們還是有點不清楚，沒關係，我們來套用一個常見的例子:
舉例來說，現在有一間公司有兩個部門會用到 NiFi 來做 Data Pipeline，此時我們可以在 NiFi Registry 建立兩個 Bucket，用來個別隸屬於兩個部門，而每個部門底下有自己的Data Pipeline Project，就可以在 Bucket 底下針對每一個 Project(也就是 Flow) 來做版本控制了。

當然讀者們也可以依據自己所屬的環境與場景來做對應的拆分，所以 Bucket 和 Flow 也就會有不同的意涵，這邊我就提一個常用的案例來讓大家理解。

為什麼是 Processor Group?

為什麼必須要以 Processor Group 為單位呢？其實不難想像，Processor Group 除了做 Module 之外，同時也作為分 Team 和分 Project 為使用，所以底下就會由一連串的 Processors 所組合而成的。所以以這個作為版控單位，才能將完整的 Data Pipeline 去做到一個控管。

還有一點是如果站在 Module 去思考，正常來說我們再引用 Module 時本來就會指定好我們可以使用的版本，所以從這個角度去想確實採用 Processor Group 作為版控單位是比較合理的選擇。

2. 與 NiFi 搭配的架構

NiFi Registry 在與 Nifi 搭配應用的架構，主要會分成兩種：

one Registry to rule them all

這個架構是 Dev, Staging 和 Production 共用同一個 NiFi Registry，雖然維護成本比較少，因為只要維護一台 NiFi Registry，但其實依據我使用的經驗，這個架構其實不太好:

1. NiFi Registry 沒有 tag 或 branch 的概念，所以今天在 NiFi Registry 代管版本時，會無法確定到目前的版本該以誰為主，以至於管理會變得很複雜。
2. 有時候我們在 Dev 交付的版本不一定就要上 Staging 或 Production，所以在此架構上也會容易造成環境之間的模糊地帶。

one Registry per environment

這個架構是 Dev, Staging 和 Production 個別維運 NiFi Registry，接著透過 nifi-toolkit 或 NiPyAPI 來做 Registry 之間的同步。我覺得這個架構是比較好的:

1. 各自環境各自作版控，環境上的切分也比較乾淨。
2. 使用者可以指定『需要』上 Staging 或 Production 的版本即可，而不用全部在 Dev 的版本都去做 synch。
3. 需要額外透過 api 的方式來做 synch，架構實作上會稍微複雜一點。
4. 但維護成本就會高一點，因為會多兩個服務去維運。

個人還是建議採用第二種架構，好好地將環境切割清楚，只 synch 需要 synch 的版本，這樣一方面可讀性好，另一方面假設有問題時也比較好去追蹤。

小總結

今天提完了這個 NiFi Registry 的用途，以及如何搭配 NiFi 的架構，明天我就會讓讀者們可以在自己的機器或筆電上啟動這兩個服務，接下來的文章都會以 1個 NiFi 搭配 1個 NiFi Registry 去做介紹，想要更複雜一點的，未來我會再提供一些資源給各位。

Reference

• Automate workflow deployment in Apache NiFi with the NiFi Registry